A Fine-Grained Access Control Method and System Based on Genealogy Data

Abstract

The present invention discloses a fine-grained access control method and system based on pedigree data. First, the role u of the current user is obtained through the attributes of user au; the result of the user authorization stage is obtained through role u; then the behavior type at is obtained through the action instance; the policy p is obtained through the σ(at) mapping relationship, and the behavior verification rule RuleAV is obtained through policy p; finally, the path rules path rules(ObjectRole, DName) are extracted from the path, and the environmental information atti of the current behavior is extracted using the ha dependency relationship; the object O is obtained through the object role ObjectRole in the path rule, and the dependency path dpath is obtained from the dependency list according to the dependency name using the τ(DName) mapping relationship; starting from the object O, the path rules in the dependency path dpath are used; relevant nodes are found through the θ(O, dpath) mapping relationship and it is evaluated whether the current environmental information meets the requirements during the operation; it is judged whether the behavior can pass the verification rule through the result set, and if it passes, conjunction or disjunction is performed; the present invention realizes finer-grained access control.

Description

Technical Field

[0001] The present invention belongs to the technical field of lineage data and access control, and relates to a fine-grained access control method and system, in particular to a fine-grained access control method and system based on lineage data. Background Art

[0002] The 21st century is an era of digitalization. With the emergence of large-scale applications and the development of mass storage technologies, the complexity of data management has been increasing day by day. Now, data has become an important strategic resource. Through various data management methods, people can find the data that meets their needs from the seemingly chaotic ocean of data, and then obtain the results or predictions they want based on data analysis. Catalyzed by the emerging data management and analysis methods, the mobility of data itself has been intensified, making it easier to copy and distribute data. In the situation of accelerating data flow, it is more difficult to trace and verify the origin of the data itself. It is possible that the data for management and analysis is incorrect, resulting in the phenomenon of GIGO (Garbage In, Garbage Out), and the data quality, credibility, and reliability cannot be guaranteed. The Measures for Data Security Management issued by the Cyberspace Administration of China in 2019 also pointed out the necessity of authenticating the data source. Therefore, in order to improve the credibility of data, it is particularly important to trace the origin of data.

[0003] In the issue of tracing the origin of data, the concept of data lineage has been proposed. Data lineage is also called the origin of data, the genealogy of data, and the lineage of data. This concept was first used in art and digital libraries, referring to the historical records of artworks and the documents that record the life cycle of digital objects, respectively. Later, it was used in the e-science community as a kind of metadata, which can be interpreted as the documents that record the origin of data objects and the processes that cause the state of objects to change. Whether in the field of scientific research or in all aspects of production and life, studying lineage data has important value and significance. Its main functions include determining the quality, credibility and reliability of data by studying its source data and derived data; querying the ownership of data sources through audit tracking of the source of data; analyzing and locating the location of errors by analyzing the derivation process of data; realizing the process and sharing of data by replaying the generation process of data; and managing the intellectual property rights and copyright of data by tracing the lineage of data. In short, the uses of data lineage are mainly concentrated in 1) data quality evaluation, 2) proof of ownership, 3) data recovery, 4) data reuse, and 5) audit tracking. As for access control technology, it is one of the key technologies to ensure information security. The main purpose of access control is to prevent objects from being illegally accessed by subjects. In simple terms, it is the restrictions set by the organization, individual or institution that owns the object on access to the object's resources. Since LAMPSON first introduced the concept of access matrix in 1969, the current access control models mainly include MAC (Mandatory Access Control), DAC (Discretionary Access Control), RBAC (Role-Based Access Control), RBAC (Rule-Based Access Control), ABAC (Attribute-Based Access Control) and their various derivative versions. The most widely used one is RBAC (Role-Based Access Control Model). However, with the advent of the information age, both government enterprises and daily life offices have a demand for more complex access control technology and fine-grained management. Traditional access control technology is built for specific purposes, so it is not easy to solve these complex requirements related to new technologies.

[0004] Lineage data has the characteristics of isolation and immutability. Among them, immutability means that once lineage data is formed, it cannot be changed. Isolation means that there is a certain causal dependency relationship among the agents, processes, and objects participating in the request. Therefore, introducing lineage data into access control is beneficial to improving the flexibility and security of the system. Lineage data is conducive to realizing a more refined access control ability because it records the pedigree information of data, the past usage information of data, the past activities of users, and version control information. For example, if an application O for rating a high-quality post is submitted in a forum system and the administrator U approves it, then the original post A becomes a high-quality post AO. The high-quality post AO is the result of the administrator U's approval of the application O, and this process is regarded as lineage data and recorded.

[0005] Currently, the research on data lineage mainly focuses on establishing lineage models, storing and querying lineage data, and a relatively complete system has been established. However, there is relatively little research on using the lineage of data in access control, and basic models such as PBAC and PAC only provide basic models that need to be combined with other access control methods. The relevant concepts in the models are often too abstract to be combined with reality. And using a single access control model based on lineage data in the system is often insufficient. Therefore, combining lineage data with traditional access control models by utilizing the characteristics of lineage data can often achieve a more fine-grained access control model, and the combination of the two will also establish new ideas for future access control research. Summary of the Invention

[0006] The purpose of the present invention is to provide a fine-grained access control method and system based on lineage data, which combines lineage data with traditional access control models by utilizing the characteristics of lineage data to achieve a more fine-grained access control.

[0007] The technical solution adopted by the method of the present invention is: a fine-grained access control method based on lineage data, which uses OPM+ as the basic model for collecting lineage data; includes the following steps:

[0008] Step 1: User authorization;

[0009] Obtain the role u of the current user through the attributes of the user au; obtain the result of the user authorization stage through the role u;

[0010] Step 2: Rule collection;

[0011] Obtain the behavior type at through the action instance, obtain the policy p through the σ(at) mapping relationship, and obtain the behavior verification rule RuleAV through the policy p; where the σ(at) mapping relationship represents the mapping from the behavior type to the policy at→p;

[0012] Step 3: Behavior verification;

[0013] Extract path rules path rules(ObjectRole, DName) from the path, and extract the environmental information atti of the current behavior using the ha dependency relationship;

[0014] Obtain the object O through the object role ObjectRole in the path rule, and obtain the dependency path dpath from the dependency list according to the dependency name using the τ(DName) mapping relationship; among them, the τ(DName) mapping relationship represents the mapping from the dependency name DName to the dependency path dpath in the dependency list, and there is exactly one dependency path corresponding to the dependency name;

[0015] Starting from the object O, use the path rule in the dependency path dpath to Find relevant nodes through the mapping relationship and evaluate whether the current environmental information meets the requirements during operation; judge whether the behavior can pass the verification rule through the result set, and if it passes, perform conjunction or disjunction; among them, The mapping relationship represents the mapping of the existing paths between resources in the pedigree graph. If there is a path path from vertex v1 to vertex v2 in the pedigree graph, it is represented as

[0016] The technical solution adopted by the system of the present invention is: a fine-grained access control system based on pedigree data, using OPM+ as the basic model for collecting pedigree data; including the following modules:

[0017] Module 1, used for user authorization;

[0018] Obtain the role u of the current user through the attributes of the user au; obtain the result of the user authorization stage through the role u;

[0019] Module 2, used for rule collection;

[0020] Obtain the behavior type at through the action instance, obtain the policy p through the σ(at) mapping relationship, and obtain the behavior verification rule RuleAV through the policy p; among them, the σ(at) mapping relationship represents the mapping from the behavior type to the policy at→p;

[0021] Module 3, used for behavior verification;

[0022] Extract path rules path rules(ObjectRole, DName) from the path, and extract the environmental information atti of the current behavior using the ha dependency relationship;

[0023] The object O is obtained through the object role ObjectRole in the path rule, and the dependency path dpath is obtained from the dependency list according to the dependency name using the τ(DName) mapping relationship; wherein the τ(DName) mapping relationship represents the mapping of the dependency name DName to the dependency path dpath in the dependency list, wherein there is only one dependency path corresponding to the dependency name;

[0024] Starting from object O, using the path rules in the dependency path dpath, through The mapping relationship finds the relevant nodes and evaluates whether the current environment information meets the requirements of the operation; the result set is used to determine whether the behavior can pass the verification rules, and if it passes, it is conjunctive or disjunctive; among them, The mapping relationship represents the mapping of the paths between resources in the lineage graph. If there is a path from vertex v1 to vertex v2 in the lineage graph, it is represented as

[0025] Compared with the prior art, the beneficial effects of the present invention include:

[0026] 1. The present invention uses OPM+ as the basic model for collecting lineage data. In addition to capturing basic lineages, it can also collect environmental information when access occurs, providing more detailed data lineage information. It can perform more fine-grained control during access control to meet complex needs.

[0027] 2. The present invention explains the sources of lineage data, namely the transaction data at the time of access request and the environmental information at that time, and introduces how the two types of lineage data are applied in access control.

[0028] 3. The present invention adopts TI-RBAC and PBACB models as basic models, combines the advantages of both, and introduces factors such as roles, permissions, and transactions. In the role authorization stage, it determines whether the user has the right to initiate the request by collecting the user's role and requesting the corresponding permissions, which simplifies the query in the user authorization stage. In the subsequent behavior verification stage, the environmental information factor is taken into account, and the user's attributes, operation attributes, and resource attributes are used as environmental information at the time of access, and are recorded in the form of transactions after the access is accepted, enriching the lineage data.

[0029] 4. The present invention introduces concepts such as roles to enrich the PBACB model, and solves the shortcomings of the PBACB model definition being too abstract and not conducive to implementation. It adds relevant mapping relationships and formal definitions, and provides a feasible solution for the access control model based on lineage data. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1It is the flowchart of the method of the embodiment of the present invention;

[0031] Figure 2 It is the result flowchart of the stage of obtaining user authorization through role u in the embodiment of the present invention;

[0032] Figure 3 It is the schematic diagram of the change of access control time with the data volume in the embodiment of the present invention. Specific implementation manners

[0033] 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 with reference to the accompanying 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.

[0034] This embodiment uses OPM+ as the basic model for collecting lineage data, and the basic parameters applied in the model are defined as follows:

[0035] Related basic sets: The set of users is U, the set of roles is R, the set of sessions is S, the access modifier set is AM (Access Modifier), the set of inheritance methods is I (Inheritance), and the set of transaction types is TT (TransactionType)

[0036] User set U = {u i | i = 1, 2, 3, 4,..., n}, representing the subjects participating in the access.

[0037] Basic role set Role Base = {r Basei | i = 1, 2, 3,..., n}, representing the base class roles in the system.

[0038] Derived role set Role Der = {r deri | i = 1, 2, 3,..., n}, representing the derived role set inherited from the base class roles.

[0039] Role set R = {r i | i = 1, 2, 3,..., n}, representing all the roles in the system

[0040] Session set S = {s i | i = 1, 2, 3,..., n}, representing the sessions in the system.

[0041] Transaction type set TT = {tt i|i=1,2,3,...,n}, represents the transaction type of the system. The transaction data T in the system is generally composed of a four-tuple (u, action, data, environment), where u refers to the user, action refers to the behavior, data refers to the data, and environment refers to the environmental factors. Permissions can be decomposed into action and data. Therefore, action and data are extracted and specified as transaction types, so that a mapping relationship from transaction type to permission can be formed.

[0042] Access modifier sets Used to indicate the access modifiers to be combined with permissions.

[0043] Inheritance method set Indicates the inheritance mode in role inheritance, and is distinguished from the access modifiers in the AM collection by capitalizing the first letter.

[0044] Permission set AMP: Here, we do not consider access modifiers and define all permissions in the system as P, where P = {p i |i=1,2,3,...,n}, but the permission P is not necessarily specific to a certain role, and in different inheritance modes, the permission will also have different access modifiers, but a permission is nothing more than one of the three modifiers: private, public, and protected. Therefore, this embodiment defines all types of permissions as AMP (Access Modifier Permission), where

[0045] Role inheritance: There are three modes of role inheritance. This embodiment supports single-role inheritance and multi-role inheritance. It can also specify to rewrite the access modifiers of some permissions during inheritance. Here, this embodiment first defines a set RC (ReConstruction). RC uses a set of two tuples to indicate that the access modifiers of the parent class role are rewritten in the subclass. The definition is as follows:

[0046] RC = {(AM old p i ,AM new p i )|i=1,2,3,...,n}, where AMoldp1 to AMoldpn represent the permissions in the parent role that need to be rewritten. new p1 to AM new p n Indicates the permissions that have been overridden in the subclass role.

[0047] Public ownership inheritance in single role inheritancesingle : Assume r1 and r2 are two roles respectively. If r2 inherits from r1 through public inheritance, it can be expressed as <r1, r2, Pub single , RC>. If RC is empty, it is considered that r2 inherits the permissions modified by public and protected in r1.

[0048] Protected inheritance Pro in single-role inheritance single : Assume r1 and r2 are two roles respectively. If r2 inherits from r1 through protected inheritance, it can be expressed as <r1, r2, Pro single , RC>. If RC is empty, it is considered that r2 inherits the permissions modified by public and protected in r1, and changes the permissions modified by public in r1 to protected.

[0049] Public inheritance Pub in multi-role inheritance mul : Assume R1 and r2 are the set of inherited roles and a single role respectively, where R1 = {r basei | i = 1, 2, 3,..., n}. If r2 inherits from R1 through public inheritance, it can be expressed as <R1, r2, Pub mul , RC>. If RC is empty, it is considered that r2 inherits the permissions modified by public of all roles in R1. Because in multi-role inheritance, the permissions modified by protected are considered as the special permissions within the department and cannot be inherited, so there is no protected inheritance in multi-role inheritance.

[0050] Private inheritance Pri: This embodiment does not consider the private inheritance of multi-role or single-role, because the purpose of both is to generate a role with corresponding empty permissions. Therefore, it can be expressed as follows. If there is a role r2 that privately inherits from role r1 or role set R1, it is all considered can be expressed as <r1, r2, pri> or <R1, r2, pri>.

[0051] Inheritance Path: An inheritance path will be formed between the base class and its derived class. For the base class role set R1 and the derived role r2, the inheritance path can be expressed as <R1, r2, Path, RC>, where Path can be expressed as I+, representing the combination of inheritance methods, and RC is the set of rewritten permissions. In this way, the permissions in the base class can be passed to the derived role through this inheritance path.

[0052] Mapping η: U → R, representing the mapping relationship between the user set and the role set.

[0053] Mapping : RBase → P represents the mapping relationship between the base class role set and the permission set.

[0054] The mapping γ: TT → P represents a mapping relationship between transaction types and permissions.

[0055] The mapping λ: T → TT represents a mapping relationship from transaction data to transaction types.

[0056] The mapping θ: R Der → P represents the mapping relationship between the roles of the derived class and the permission set. An inheritance path will be formed between the base class roles and the derived roles. The AMP in the base class roles can be converted into the permission set of the derived roles through the inheritance path, and the corresponding relationship between the derived roles and permissions can be analyzed through the inheritance relationship of the roles.

[0057] After introducing the relevant model components, some parameters used in this embodiment are given below:

[0058] The access request request(au, a, o) represents the user (U), action instance (ActionInstance), and the resource object (Object) being accessed in the access request. The user U has been defined. Below, AI and O are introduced separately;

[0059] Action instance: AI = {a i | i = 1, 2, 3,..., n}, and the action instance describes the specific actions that the user in the access request will perform on the accessed data;

[0060] Action type: AT = {at i | i = 1, 2, 3,..., n}, and the action type can be abstracted from specific action instances. For example, user A submits (SubmitA) a post (Postsubmit). Here, SubmitA is a specific action instance, while Submit represents the type of this action. Assume that the system can find the policy related to Submit from the given policies.

[0061] Resource object: O = {o i | i = 1, 2, 3,..., n}, representing the types of resources to be accessed. In specific application scenarios, different subscripts will be marked for the resource O according to different action types. Here, it can be understood as the role (Objectrole) of the resource O.

[0062] Policy set (Policy): The access policies formulated for actions. For example, a post cannot be commented by a person who has been muted. Such policies are predefined by the system and can be obtained according to the action type AT.

[0063] AttributeSet (Attribute): ATT = {att i | i = 1, 2, 3,..., n}, where the attributes are divided into three types, namely the attributes of the user, the attributes of the operation, and the attributes of the resource. The three types of attributes will store relevant information during the access request and provide relevant information during the access control judgment. Here, the attribute information is mainly added to the behavior because when the access request occurs, saving the user information, behavior information, and resource information to the behavior can facilitate storage and query more conveniently.

[0064] Provenance Data: PD = PD B ∪ PD E , where PD B refers to the transaction data converted from the system transaction after the request is executed, and PD E refers to the environmental factors during the specific operation process, such as time, personnel, location, system environment, and other relevant information. They will also be recorded in the form of transaction data and converted into the environmental information of the Action.

[0065] Provenance Graph: The provenance graph is composed of a triple and is a directed acyclic graph describing the data dependency relationship. Specifically, it can be described as <V E , E E , D E >, where the subscript E indicates that this provenance graph is an extended provenance graph based on PBAC.

[0066] V E = U ∪ AI ∪ O ∪ ATT, which defines the types of vertices in the provenance graph, including user, action, resource, and attribute nodes;

[0067] D E = G ∪ {'c'} ∪ U ∪ HA ∪ G -1 ∪ {'c -1 '} ∪ U -1 ∪ HA -1 , which defines the basic dependency relationships in the provenance graph.

[0068] defines the types of edges in the provenance graph. The dependency relationships have been introduced in the OPM+ model. 'c' represents wasControlledBy, U represents Used, G represents wasGeneratedBy, HA represents hasAttributeOf. Adding the reverse relationships is mainly to facilitate traversing the provenance graph more conveniently.

[0069] Dependency Name (DN): DN = {dn i | i = 1, 2, 3,..., n}, where the dependency name uses an abstract name to name a dependency relationship.

[0070] Dependency Path (DPATH): Assume that ∑ is the union of DN and DE, then the dependency path will be defined in the following way:

[0071]

[0072] (P1 | P2), (P1.P2), P1*, P1 + , P1 ？ ∈ DPATH, where P1, P2 ∈ DPATH.

[0073] Dependency List: It is a binary tuple composed of a dependency name and a dependency path, and the dependency name is unique. Here, the dependency name can appear in the dependency path and re - define the dependency name as part of the dependency path. For example, in the following dependency list, there are two dependency names, and one dependency name can be used in the other dependency path.

[0074] <was ReviewedBy, was ReviewedOof -1 .g review .c >,

[0075] <was ReviewedOof, g review .u input >,

[0076] Among them, wasReviewedOof is a dependency name defined by the combination of the Used relationship and the wasGeneratedBy dependency, and then it can be used in the dependency path of wasReviewedBy. Through this definition method, the creation of the dependency list is completed.

[0077] Policy: The policy can be generated using the syntax defined in Table 1 and form a form similar to the following: Which means that the user au replacing the resource o needs to meet the condition that the user's role is role i And the resource o has not been submitted.

[0078] Table 1 Policy Generation Syntax

[0079]

[0080]

[0081] The mapping σ: AT → P represents the mapping from the behavior type to the policy.

[0082] The mapping τ: DN → DPATH represents the mapping from the dependency name to the dependency path in the dependency list, where there is exactly one dependency path corresponding to the dependency name.

[0083] Mapping : represents the mapping of the existing paths between resources in the pedigree graph. If there is a path path from vertex v1 to vertex v2 in the pedigree graph, it can be represented as

[0084] Please refer to Figure 1 , a fine-grained access control method based on pedigree data provided by the present invention, uses OPM+ as the basic model for collecting pedigree data; includes the following steps:

[0085] Step 1: User authorization;

[0086] Obtain the role u of the current user through the attributes of the user au; obtain the result of the user authorization phase through the role u;

[0087] Please refer to Figure 2 , in this embodiment, the result of the user authorization phase is obtained through the role u, and the specific implementation includes the following sub-steps:

[0088] Step 1.1: The user sends an access control request, which includes four elements: the user u, the behavior, the data, and the current environmental conditions;

[0089] Step 1.2: Find the role role of the user u through the η(u) mapping relationship u ; where the η(u) mapping relationship represents the mapping relationship between the user set and the role set;

[0090] Step 1.3: If then find the corresponding permission set P1 through the mapping relationship;

[0091] If then find the corresponding permission set P2 through the θ(role u ) mapping relationship;

[0092] where, Role Base = {r Basei |i = 1, 2, 3,..., n} represents the base class role; Role Der = {r deri |i = 1, 2, 3,..., n}, represents the set of derivative roles inherited from the base class role; n is the number of users; The mapping relationship represents the mapping relationship between the base class role set and the permission set; θ(role u ) The mapping relationship represents the mapping relationship between the role of the derived class and the permission set;

[0093] Step 1.4: Use the λ mapping relationship to find the corresponding transaction type based on the behavior and data; where the λ mapping relationship represents a mapping relationship from transaction data to transaction type;

[0094] Step 1.5: Use the γ(TT) mapping relationship to find the permission Permission corresponding to the transaction type, where the γ(TT) mapping relationship represents a mapping relationship between the transaction type and the permission;

[0095] Step 1.6: If the permission Permission belongs to set P1 or P2, accept the request and write the transaction data to the corresponding role role u ; otherwise, reject the request and perform a transaction rollback operation.

[0096] Step 2: Rule collection;

[0097] Obtain the behavior type at through the action instance, obtain the policy p through the σ(at) mapping relationship, and obtain the behavior verification rule RuleAV through the policy p; where the σ(at) mapping relationship represents the mapping from the behavior type to the policy at→p;

[0098] Step 3: Behavior verification;

[0099] Extract the path rules path rules(ObjectRole,DName) from the path, and use the ha dependency relationship to extract the environmental information atti of the current behavior;

[0100] Obtain the object O through the object role ObjectRole in the path rule, and use the τ(DName) mapping relationship to obtain the dependency path dpath from the dependency list according to the dependency name; where the τ(DName) mapping relationship represents the mapping from the dependency name DName to the dependency path dpath in the dependency list, and there is exactly one dependency path corresponding to the dependency name;

[0101] Starting from the object O, use the path rules in the dependency path dpath, through the mapping relationship to find the relevant nodes and evaluate whether the current environmental information meets the requirements during the operation; judge whether the behavior can pass the verification rule through the result set, and if it passes, perform conjunction or disjunction; where the mapping relationship represents the mapping of the existing paths between resources in the pedigree diagram. If there is a path path from vertex v1 to vertex v2 in the pedigree diagram, it is represented as

[0102] This embodiment is a feasible method for access control based on lineage data proposed to address the increasingly complex access requirements. It combines concepts related to roles, role inheritance, and permissions, simplifies the access process, and achieves fine-grained access control.

[0103] Please refer to Figure 3 , which is an application example of this embodiment. As the lineage data increases, the change in the time taken to complete access control can be seen from the figure. After increasing to 3,000 items, the time is still within an acceptable range. Thus, it can be seen that the present invention has good application effects.

[0104] It should be understood that the above description of the preferred embodiment is relatively detailed, and it should not be considered as a limitation to the protection scope of the present invention. Under the inspiration of the present invention, those of ordinary skill in the art can also make substitutions or deformations without departing from the protection scope defined by the claims of the present invention, and all fall within the protection scope of the present invention. The scope of protection claimed by the present invention shall be subject to the appended claims.

Claims

1. A fine-grained access control method based on lineage data, using OPM+ as the basic model for collecting lineage data; characterized in that, It includes the following steps: Step 1: User authorization; Obtain the role of the current user through the user au ; Obtain the result of the user authorization phase through the role u ; u Obtain the result of the user authorization phase; The result of the user authorization phase obtained through the role u Specific implementation includes the following sub-steps: Step 1.1: The user sends an access control request, which contains four elements: the user u , behavior, data, and the environmental conditions at that time; Step 1.2: Through the mapping relationship, find the u role of the user role u ; where the mapping relationship represents the mapping relationship between the user set and the role set; Step 1.3: If , then find the permission set P1 corresponding to this role through the mapping relationship; If , then find the permission set P2 corresponding to this role through the mapping relationship; Among them, represents the base class role; , represents the set of derived roles inherited from the base class role; n is the number of users; The mapping relationship represents the mapping relationship between the base class role set and the permission set; The mapping relationship represents the mapping relationship between the roles of the derived class and the permission set; Step 1.4: Through the mapping relationship, find the corresponding transaction type using the behavior and data; among them, the mapping relationship represents a mapping relationship from transaction data to transaction type; Step 1.5: Through the mapping relationship, find the corresponding permission Permission for the transaction type, where the mapping relationship represents a mapping relationship between the transaction type and the permission; Step 1.6: If the permission Permission belongs to set P1 or P2, accept the request and write the transaction data to the corresponding role role; otherwise, reject the request and perform a transaction rollback operation; u Otherwise, reject the request and perform a transaction rollback operation; Step 2: Rule collection; Obtain the behavior type through the action instance at , through the mapping relationship to obtain the policy p , through the policy p obtain the behavior verification rule RuleAV; where the mapping relationship represents the mapping from the behavior type to the policy ; Step 3: Behavior verification; Extract path rules path rules(ObjectRole,DName) from the path, and use ha Dependency relationship to extract the environmental information of the current behavior atti ; Obtain the object O through the object role ObjectRole in the path rule, and use The mapping relationship to obtain the dependency path from the dependency list according to the dependency name dpath ; where The mapping relationship indicates that in the dependency list, the dependency name to the dependency path dpath The mapping, where there is exactly one dependency path corresponding to the dependency name; Starting from object O, using the path rules in dpath , find relevant nodes through the mapping relationship and evaluate whether the current environmental information meets the requirements during operation; determine whether the behavior can pass the verification rules through the result set, and if it passes, perform conjunction or disjunction; among them, the mapping relationship represents the mapping of the existing paths between resources in the genealogy graph. If there is a path path from vertex v1 to vertex v2 in the genealogy graph, it is represented as .

2. A fine-grained access control system based on lineage data, which uses OPM+ as the basic model for collecting lineage data; characterized in that, It includes the following modules: Module 1, for user authorization; Obtain the role of the current user through the attributes of the user au ; Obtain the result of the user authorization phase through the role u ; Obtain the result of the user authorization phase through the role u ; The result of the user authorization stage obtained through the role u Specific implementation includes the following sub-modules: Module 1.1 is used for the user to send an access control request, which includes four elements: the user u , behavior, data, and the environmental conditions at that time; Module 1.2, which is used to find the user's u role role u ; where the mapping relationship represents the mapping relationship between the user set and the role set; Module 1.3, for if , then through the mapping relationship to find the permission set P1 corresponding to this role; If , then find the permission set P2 corresponding to this role through the mapping relationship; Among them, represents the base class role; , represents the set of derived roles inherited from the base class role; n is the number of users; The mapping relationship represents the mapping relationship between the base class role set and the permission set; The mapping relationship represents the mapping relationship between the roles of the derived class and the permission set; Module 1.4, for finding the corresponding transaction type by using the mapping relationship to find the corresponding transaction type using behavior and data; wherein, the mapping relationship represents a mapping relationship from transaction data to transaction type; Module 1.5, for passing through the mapping relationship to find the corresponding permission Permission for the transaction type, where the mapping relationship represents a mapping relationship between the transaction type and the permission; Module 1.6, which is used to accept a request and write transaction data to the corresponding role if the permission belongs to set P1 or P2; otherwise, reject the request and perform a transaction rollback operation. u Otherwise, reject the request and perform a transaction rollback operation; Module 2, for rule collection; Obtain the behavior type through action instances at , through the mapping relationship to obtain the policy p , through the policy p obtain the behavior verification rule RuleAV; where the mapping relationship represents the mapping from the behavior type to the policy ; Module 3, for behavior verification; Extract path rules path rules(ObjectRole, DName) from the path and use ha Dependency relationship to extract the environmental information of the current behavior atti ; Obtain the object O through the object role ObjectRole in the path rule, and use the mapping relationship to obtain the dependency path from the dependency list according to the dependency name dpath ; where the mapping relationship indicates that in the dependency list, the dependency name to the dependency path dpath mapping, where there is exactly one dependency path corresponding to the dependency name; Starting from the object O, using the path rules in dpath , find the relevant nodes through the mapping relationship and evaluate whether the current environmental information meets the requirements during operation; judge whether the behavior can pass the verification rules through the result set, and if it passes, perform conjunction or disjunction; among them, the mapping relationship represents the mapping of the paths existing between resources in the pedigree diagram. If there is a path path from vertex v1 to vertex v2 in the pedigree diagram, it is represented as .

Images