Multi-role data access control system for industry collaboration

Abstract

The invention relates to a multi-role data access control system for industrial collaboration, and discloses a strategy generation mechanism driven by a main body relation collaboration graph and a collaboration contract, a joint judgment model and a unified executable constraint packet and multi-execution-point forcing mechanism. And the multi-role data access control system realizes fine control on business data, report data, process data, interface calling and log data. The system is characterized by comprising a main body and identity module, a resource registration and object modeling module, a collaborative contract and strategy instance module, a strategy and control module, a process linkage and life cycle module and a full-link audit and evidence storage module, and a collaborative relation graph between the main body and the resource entity is constructed, and the resource registration and object modeling module outputs a structured resource object.

Description

Technical Field

[0001] This invention relates to a multi-role data access control system for industry collaboration, belonging to the field of access control technology. Specifically, it relates to a multi-role data access control system that achieves refined control over business data, report data, process data, interface calls, and log data through a subject relationship collaboration graph, a strategy generation mechanism driven by collaboration contracts, a joint decision model, and a unified executable constraint package and multi-execution point enforcement mechanism. Background Technology

[0002] As business segments such as coal, power, chemicals, logistics, and new materials gradually develop towards group-based, platform-based, and collaborative models, the internal business structure of enterprises has shifted from a vertical management model based on a single system and organization to a complex operational model involving cross-segment, cross-organization, cross-system, and multi-role collaboration. In scenarios such as production scheduling, supply chain collaboration, safety supervision, comprehensive oversight, and third-party collaboration, the same business data frequently flows between different stages and different entities, resulting in dynamically changing data access boundaries. Existing information systems still employ static authorization methods based on roles or system menus, with permissions strongly bound to positions and systems. This makes it difficult to adapt to the dynamic collaboration needs across business domains and process stages. In a group-based operating environment, this model generally presents the following problems: First, it is difficult to precisely distinguish the access permissions of different roles for the same data object, easily leading to unauthorized access or cross-permission leaks; second, data access behavior is disconnected from the business process status, and permissions cannot be automatically revoked after the process ends, creating a security risk of "long-term authorization and hidden exposure."

[0003] Publication No. CN112035853A discloses a storage data access control system based on an enterprise cloud disk, including: a cloud storage server SCS set up on an enterprise cloud platform, a computer terminal PCTS / R used to upload data to the enterprise cloud disk and access data on the enterprise cloud disk, and a cloud authorization server SCA running cloud data access authorization system software and set up on the enterprise cloud platform; when a user US / R on the computer terminal PCTS / R encrypts data m into σ and uploads it to the cloud storage server SCS for storage, and then sends an access request to the cloud storage server SCS, the cloud data access authorization system must perform access control on the user US / R on the computer terminal PCTS / R. Only when the identity of the user US / R on the computer terminal PCTS / R is authenticated by the cloud data access authorization system is access to the encrypted data σ stored on the cloud storage server SCS allowed. Publication No. CN111259352A discloses a cloud storage data access control system based on zero-knowledge proof, including: a cloud storage server Si configured with a cloud storage database Di, on which cloud storage access control system software runs; and an access client Ui, which communicates with the cloud storage server Si; when the access client Ui sends a data access request to the cloud storage database Di of the cloud storage server Si, the cloud storage access control system of the cloud storage server Si uses an access verification method based on zero-knowledge proof to verify the identity of the access client Ui, and only the access client Ui that has passed the identity verification is allowed to access the data in the cloud storage database Di of the cloud storage server Si. The aforementioned system still adopts a role-based static authorization method, with permissions strongly bound to positions and systems. This makes it difficult to adapt to the dynamic collaboration needs across business domains and process stages. In a group-based operating environment, this model generally has the following problems: First, it is difficult to distinguish the access permissions of different roles to the same data object, which can easily lead to unauthorized access or cross-permission leakage. Second, data access behavior is disconnected from the business process status, and permissions cannot be automatically revoked after the process ends, resulting in the security risk of "long-term authorization and hidden exposure". Summary of the Invention

[0004] To improve the above situation, the present invention provides a multi-role data access control system for industry collaboration. This system provides a multi-role data access control system that achieves fine-grained control over business data, report data, process data, interface calls and log data through a subject relationship collaboration graph, a strategy generation mechanism driven by collaboration contracts, a joint decision model, and a unified executable constraint package and multi-execution point enforcement mechanism.

[0005] The present invention discloses a multi-role data access control system for industry collaboration, which is implemented as follows: The multi-role data access control system for industry collaboration includes a subject and identity module, a resource registration and object modeling module, a collaboration contract and strategy instance module, a strategy and control module, a process linkage and lifecycle module, and a full-link audit and evidence sealing module. The system is characterized by the following features: the subject and identity module outputs standardized identity tokens and session contexts to construct a collaborative relationship graph between subjects and resource entities; the resource registration and object modeling module outputs structured resource objects; the collaborative contract and policy instance module constructs collaborative contracts and supports parameter writing, generating a set of structured policy instances; the policy and control module inputs the outputs of the aforementioned modules into the fused access control model, outputs access decisions, and deploys policy execution points in multiple access channels to execute distributed control behaviors based on the access decision results; the process linkage and lifecycle module constructs a unified event flow from the state changes of collaborative services through an event bus and linkage controller, and performs permission change processing; and the end-to-end audit and evidence sealing module forms a traceable and provable log through audit events, constraint summaries, and exported watermarks and file fingerprints. The subject and identity module is used for unified identity authentication and to construct a subject resource collaboration relationship graph. The subject and identity module includes a unified identity and authentication adapter and a subject relationship and collaboration graph submodule. The unified identity and authentication adapter is used for unified access through multi-source authentication. It transforms authentication results into computable attributes through standardized identity representation and session context, which are then used by subsequent modules for judgment. The unified identity and authentication adapter outputs standardized identity tokens and session contexts. Preferably, the token model is an opaque token + session ID. Preferably, the token contains only the minimum necessary declarations, including sub (subject identifier), org (organization), roles (basic role set), assurance_level (authentication strength level), and other necessary declarations, avoiding cramming too much sensitive information into the token. Preferably, the session context includes authentication method and strength, terminal trustworthiness, risk marker, bound collaborative identity mapping, and other content describing the session environment, which is read and associated with the Opaque Token. Preferably, the unified identity and authentication adapter is equipped with a risk-enhanced authentication module, which uses a step-up authentication model to perform secondary verification for high-risk actions. Preferably, the high-risk actions include data outbound actions, cross-domain expansion actions, critical change actions, and other high-risk actions that require elevation authentication. The subject relationship and collaboration graph submodule is used to construct a collaboration relationship graph between subjects and resource entities, providing a computable, queryable, and determinate relationship network to ensure that data access authorization is based on business relationship facts rather than identity or role labels. The subject relationship and collaboration graph submodule uses a property graph model to construct the collaboration relationship graph. In this property graph model, vertices represent entities, and edges represent relationships between entities. Both vertices and edges carry attributes. Preferably, the entity types include subject classes, resource classes, and other types that can serve as vertices. The subject classes include users, organizations, positions, work groups, third-party collaborating entities, and other types of entities. The resource classes include projects, work orders, contracts, scheduling tasks, processes, and other business collaboration data resources. Preferably, the relationships between the entities include subordinate relationships, participation relationships, carrier relationships, approval relationships, regulatory relationships, and other types of relationships that represent connections between entities. The vertex attributes describe the feature information of the entity itself, and the edge attributes describe the constraints and context information of the relationships between entities. Preferably, the subject relationship and collaboration graph submodule determines relationships through relationship existence and relationship path constraints, checking whether a satisfactory relationship link exists between the subject and the resource to avoid generalized authorization. Preferably, the relationship path constraint includes the length, edge type, direction, validity period, and other constraints of the relationship link. An optional path constraint rule includes: starting point type, ending point type, allowed edge sequence, maximum length, and additional constraints. Preferably, the subject relationship and collaboration graph submodule calls the structured resource objects from the resource registration and object modeling module as resource entities. The resource registration and object modeling module is used to perform unified resource modeling on scattered business data, reports, processes, interfaces, and operation records, and output structured resource objects. The resource object is defined as: Resource = {rid, type, domain, system, sensitivity, actions, attributes, lineage}.

[0006] Wherein, `rid` is the unique identifier of the resource in the system, `type` is the resource type, `domain` is the business unit or governance domain to which the resource belongs, `system` is the business system from which the resource originates, `sensitivity` is the resource sensitivity level, `actions` is the set of executable actions for the resource, `attributes` is the set of extended attributes for the resource, and `lineage` is the data lineage, describing the reference relationships between resources. The collaborative contract and strategy instance module is used to construct standardized authorization templates and write structured strategy instances through parameters. The collaborative contract and strategy instance module includes a collaborative contract and authorization work order sub-module and a strategy orchestration and template engine. The collaborative contract and authorization work order submodule is used to solidify the authorization reasons and authorization boundaries into a machine-readable collaborative contract, binding permissions to collaborative tasks and strongly associating them with actual business operations. The collaborative contract is defined as Contract = {cid, subject_set, resource_set, action_set, scope, constraints, start / end, approvals, revocation_rules}.

[0007] Wherein, cid represents the contract ID, subject_set represents the set of authorized subjects, resource_set represents the set of authorized resources (indicating which resources are allowed to be accessed in this collaborative task), action_set represents the set of allowed actions, scope represents the authorized business boundary, constraints represent additional constraints, start / end represents the contract validity period, approvals represent approval and confirmation information, and revocation_rules represent revocation rules. Preferably, the subject_set is a collaborative relationship graph between subject-resource entities constructed by the subject relationship and collaborative graph submodule. Preferably, the resource_set is a structured resource object output by the resource registration and object modeling module. Preferably, the collaborative contract and authorized work order submodule performs access permission shrinkage calculation through least-privilege closure. The least-privilege closure, EffectivePerm = BasePerm(subject) ∩ ContractPerm ∩ DomainBaselinePerm, Here, BasePerm(subject) represents the basic permissions that the subject possesses without considering the current collaboration, ContractPerm represents the set of permissions explicitly authorized by the collaboration contract, and DomainBaselinePerm represents the group-level or domain-level security baseline policy. The policy orchestration and template engine provides administrators, security personnel, or business administrators with template-based parameterized policy configurations, avoiding the writing of arbitrary rules. It fills in parameters according to predefined policy formats and outputs structured policy instances. The predefined strategy form is the collaborative contract template provided by the collaborative contract and authorized work order submodule. Preferably, the strategy orchestration and template engine introduces Rego (OPA) as the execution backend. Preferably, the strategy orchestration and template engine introduces a conflict resolution algorithm, which preferably combines explicit denial-overrides with the principle of least privilege. The strategy and control module is used to output the access policy determination result and execute the access policy based on the determination result. The strategy and control module includes a strategy decision engine (PDP) submodule and a strategy execution point (PEP) submodule. The Policy Decision Engine (PDP) submodule integrates multiple access control models based on roles, attributes, and relationships, and combines them with policy instances generated by collaborative contracts to calculate executable access decisions, enabling online determination of access requests. The Policy Decision Engine (PDP) submodule takes into input standardized identity tokens and session context, subject-resource entity collaboration graph, structured resource objects, and structured policy instances. After calculation by the decision model, it outputs an access decision, which includes an executable constraint package and additional security action flags. The access decision is defined as Decision = {permit_or_deny, constraint_pack, security_mark}. The decision model is based primarily on ABAC, supplemented by RBAC, and further enhanced by ReBAC. The specific expression of the decision model is as follows: Decision = f( RBAC_base(user), ABAC_attr(user, resource, env), ReBAC_rel(graph, user, resource), Contract_ctx(contract, now, process_state), Policy_set(policy_instances, deny_overrides, permit_minimization) ), Here, RBAC_base(user) represents the basic qualifications and admission boundaries of the subject; ABAC_attr(user,resource, env) represents the attribute condition matching status; ReBAC_rel(graph, user, resource) represents the existence of the collaborative relationship and the satisfaction of path constraints; Contract_ctx(contract, now, process_state) represents the collaborative contract and its validity, revocation rules and state linkage constraints; and Policy_set(policy_instances, deny_overrides, permit_minimization) represents the matching and conflict resolution of the policy instance set. Preferably, the Policy Decision Engine (PDP) submodule is configured with a high-frequency decision caching mechanism to cache PDP decision results and generate a data constraint expression and template library. This data constraint expression and template library includes cached executable constraint packages for use by the Policy Execution Point (PEP) submodule. The result cache key is defined as hash(user_id, session_id, resource_type, action, scope_version). Where user_id represents the principal ID, session_id represents the session ID, resource_type represents the resource type, action represents the action, and scope_version represents the version number of the authorization-related facts. Preferably, the cache invalidation triggering events include organizational changes, job changes, termination of collaborative contracts, changes in process nodes, entity exit, and other events that cause cache invalidation. Preferably, the executable constraint package includes row-level constraints, column-level constraints, and index-level constraints. Preferably, the row-level constraints use a filter expression template, the column-level constraints use a standardized expression combining a field whitelist or blacklist with a desensitization function, and the indicator-level constraints use a combination of an indicator allow list, drill-down depth, and export restrictions. The Policy Execution Point (PEP) submodule deploys policy execution points across multiple access channels, including data querying, report access, process operations, API calls, and log retrieval, forming a distributed execution matrix that transforms policy decision results into unavoidable mandatory actions. The distributed execution matrix includes PEP-gateway, PEP-data service, PEP-reporting service, PEP-process engine, and PEP-log retrieval. The PEP gateway intercepts requests, verifies identity tokens and session contexts, calls the PDP to obtain decision results to control API calls, service calls, and third-party access requests, and injects executable constraint packages into downstream services. The downstream services process requests solely based on these executable constraint packages, without further determining permissions themselves, ensuring centralized and consistent access control logic. The PEP-data service executes row-level and column-level constraints during the query phase and index-level constraints during the export phase. After export, it automatically overlays watermarks and generates file fingerprints. The PEP-reporting service controls the visibility of directories and components, limits the displayable metrics and drill-down depth, and controls report export based on the executable constraint package. The PEP-process engine controls the visibility and editability of fields at the process node level based on the executable constraint package, and executes button and action controls. Process write-back operations are only allowed on the set of fields specified by the constraint package. The PEP-Log Retrieval incorporates logs as resource objects into the access control system, performs minimal disclosure by domain and responsibility, and anonymizes sensitive fields. Preferably, in the distributed execution matrix, different execution points parse the same constraint package based on a uniformly defined executable constraint package structure and implement corresponding constraints in their respective execution contexts, thereby achieving end-to-end control over the data access scope, content, and operational capabilities. The process linkage and lifecycle module is used to transform real-world state changes in the business system into calculable and triggerable event flows, thereby driving the automatic adjustment of collaborative contracts, strategy instances, executable constraint packages, and cached versions, achieving full lifecycle management from "activation to tightening to freezing to recycling." The process linkage and lifecycle module includes an event bus and a linkage controller. The event bus integrates status changes from the process engine, work order system, contract system, organizational and personnel systems, third-party collaboration platforms, and other collaborative business processes into unified events, and delivers them to the linkage controller for permission change processing. The event model is defined as Event = {type, entity_id, from_state, to_state, timestamp, emitter, signature}. Wherein, type represents the event type, entity_id represents the ID of the event object, from_state represents the state before the state transition, to_state represents the state after the state transition, timestamp represents the time the event occurred, emitter represents the source of the event, and signature represents the event signature or integrity verification information. The method for implementing the linkage controller from event to permission change includes: 1) Verify events: Check the signature, emitter whitelist, and time window to prevent forgery and replay. 2) Normalization and Mapping: Map the entity_id to the authorization object. 3) Trigger the lifecycle state machine: Drive permission state transitions according to event rules. 4) Issue changes: Update the policy instance, update the constraint package policy template parameters, increment the version number to invalidate the cache, and write to the audit and evidence index. The permission lifecycle state machine includes Grant (pending activation) → Active (activated) → Tighten (tightened) → Freeze (frozen) → Revoke (revoked) or Expire (expired). The triggering conditions of the state machine are defined by event rules. The event rule is written as follows: when type = a certain type of event and to_state = a certain set, a state transition is triggered, along with an action. The process linkage and lifecycle module introduces an automatic recycling algorithm. When to_state ∈ {Completed,Terminated} or now > end_time, all policy instances associated with cid are revoked and written to the sealed evidence index. The end-to-end auditing and evidence sealing module generates a traceable and verifiable log by analyzing audit events, constraint summaries, and exporting watermarks and file fingerprints. The end-to-end audit and evidence sealing module is strongly bound to three types of information: access requests, decision-making basis, and execution results. The audit event is defined as: Audit = {request_id, user, action, resource, decision, constraint_digest, policy_id, contract_id, result_summary, device, ip, time}. In this context, `request_id` represents the primary key for end-to-end tracing, `user` represents the subject identifier, `action` represents the access action, `resource` represents the resource object, `decision` represents the PDP decision result, `constraint_digest` represents the constraint package digest, `policy_id` represents the policy instance, `contract_id` represents the collaboration contract, `result_summary` represents the execution result digest, and `device`, `ip`, and `time` represent environment authentication fields, provided by the standardized identity token and session context. The constraint digest, `constraint_digest = hash(constraint_pack)`, is used to prove the allowed boundaries at that time. The exported watermark and file fingerprint are defined as: watermark_text = user_id + time + contract_id + policy_id + request_id; the file fingerprint is hashed and archived. Preferably, the end-to-end auditing and evidence sealing submodule incorporates the Isolation Forest algorithm for outlier detection. Beneficial effects

[0008] 1. By binding access permissions to specific projects, work orders, contracts, or process tasks through collaborative contracts, permissions can be dynamically adjusted as collaborative tasks are generated, changed, and terminated, thereby achieving data access control centered on collaborative tasks and avoiding security risks caused by long-term static authorization.

[0009] Second, by constructing a collaborative relationship graph between subject and resource entities and introducing relationship existence and path constraints in access determination, it is possible to accurately determine whether there is a legitimate collaborative relationship between the subject and the resource, thereby avoiding permission overlap and unauthorized access caused by complex organizational hierarchies or third-party participation. Detailed Implementation

[0010] The multi-role data access control system for industry collaboration of the present invention is implemented as follows: The multi-role data access control system for industry collaboration of the present invention includes a subject and identity module, a resource registration and object modeling module, a collaboration contract and strategy instance module, a strategy and control module, a process linkage and lifecycle module, and a full-link audit and evidence sealing module. The system is characterized by the following features: the subject and identity module outputs standardized identity tokens and session contexts to construct a collaborative relationship graph between subjects and resource entities; the resource registration and object modeling module outputs structured resource objects; the collaborative contract and policy instance module constructs collaborative contracts and supports parameter writing, generating a set of structured policy instances; the policy and control module inputs the outputs of the aforementioned modules into the fused access control model, outputs access decisions, and deploys policy execution points in multiple access channels to execute distributed control behaviors based on the access decision results; the process linkage and lifecycle module constructs a unified event flow from the state changes of collaborative services through an event bus and linkage controller, and performs permission change processing; and the end-to-end audit and evidence sealing module forms a traceable and provable log through audit events, constraint summaries, and exported watermarks and file fingerprints. The subject and identity module is used for unified identity authentication and to construct a subject resource collaboration relationship graph. The subject and identity module includes a unified identity and authentication adapter and a subject relationship and collaboration graph submodule. The unified identity and authentication adapter is used for unified access through multi-source authentication. It transforms authentication results into computable attributes through standardized identity representation and session context, which are then used by subsequent modules for judgment. The unified identity and authentication adapter outputs standardized identity tokens and session contexts. Preferably, the token model is an opaque token + session ID. Preferably, the token contains only the minimum necessary declarations, including sub (subject identifier), org (organization), roles (basic role set), assurance_level (authentication strength level), and other necessary declarations, avoiding cramming too much sensitive information into the token. Preferably, the session context includes authentication method and strength, terminal trustworthiness, risk marker, bound collaborative identity mapping, and other content describing the session environment, which is read and associated with the Opaque Token. Preferably, the unified identity and authentication adapter is equipped with a risk-enhanced authentication module, which uses a step-up authentication model to perform secondary verification for high-risk actions. Preferably, the high-risk actions include data outbound actions, cross-domain expansion actions, critical change actions, and other high-risk actions that require elevation authentication. The subject relationship and collaboration graph submodule is used to construct a collaboration relationship graph between subjects and resource entities, providing a computable, queryable, and determinate relationship network to ensure that data access authorization is based on business relationship facts rather than identity or role labels. The subject relationship and collaboration graph submodule uses a property graph model to construct the collaboration relationship graph. In this property graph model, vertices represent entities, and edges represent relationships between entities. Both vertices and edges carry attributes. Preferably, the entity types include subject classes, resource classes, and other types that can serve as vertices. The subject classes include users, organizations, positions, work groups, third-party collaborating entities, and other types of entities. The resource classes include projects, work orders, contracts, scheduling tasks, processes, and other business collaboration data resources. Preferably, the relationships between the entities include subordinate relationships, participation relationships, carrier relationships, approval relationships, regulatory relationships, and other types of relationships that represent connections between entities. The vertex attributes describe the feature information of the entity itself, and the edge attributes describe the constraints and context information of the relationships between entities. Preferably, the subject relationship and collaboration graph submodule determines relationships through relationship existence and relationship path constraints, checking whether a satisfactory relationship link exists between the subject and the resource to avoid generalized authorization. Preferably, the relationship path constraint includes the length, edge type, direction, validity period, and other constraints of the relationship link. An optional path constraint rule includes: starting point type, ending point type, allowed edge sequence, maximum length, and additional constraints. Preferably, the subject relationship and collaboration graph submodule calls the structured resource objects from the resource registration and object modeling module as resource entities. The resource registration and object modeling module is used to perform unified resource modeling on scattered business data, reports, processes, interfaces, and operation records, and output structured resource objects. The resource object is defined as: Resource = {rid, type, domain, system, sensitivity, actions, attributes, lineage}.

[0011] Wherein, `rid` is the unique identifier of the resource in the system, `type` is the resource type, `domain` is the business unit or governance domain to which the resource belongs, `system` is the business system from which the resource originates, `sensitivity` is the resource sensitivity level, `actions` is the set of executable actions for the resource, `attributes` is the set of extended attributes for the resource, and `lineage` is the data lineage, describing the reference relationships between resources. The collaborative contract and strategy instance module is used to construct standardized authorization templates and write structured strategy instances through parameters. The collaborative contract and strategy instance module includes a collaborative contract and authorization work order sub-module and a strategy orchestration and template engine. The collaborative contract and authorization work order submodule is used to solidify the authorization reasons and authorization boundaries into a machine-readable collaborative contract, binding permissions to collaborative tasks and strongly associating them with actual business operations. The collaborative contract is defined as Contract = {cid, subject_set, resource_set, action_set, scope, constraints, start / end, approvals, revocation_rules}.

[0012] Wherein, cid represents the contract ID, subject_set represents the set of authorized subjects, resource_set represents the set of authorized resources (indicating which resources are allowed to be accessed in this collaborative task), action_set represents the set of allowed actions, scope represents the authorized business boundary, constraints represent additional constraints, start / end represents the contract validity period, approvals represent approval and confirmation information, and revocation_rules represent revocation rules. Preferably, the subject_set is a collaborative relationship graph between subject-resource entities constructed by the subject relationship and collaborative graph submodule. Preferably, the resource_set is a structured resource object output by the resource registration and object modeling module. Preferably, the collaborative contract and authorized work order submodule performs access permission shrinkage calculation through least-privilege closure. The least-privilege closure, EffectivePerm = BasePerm(subject) ∩ ContractPerm ∩ DomainBaselinePerm, Here, BasePerm(subject) represents the basic permissions that the subject possesses without considering the current collaboration, ContractPerm represents the set of permissions explicitly authorized by the collaboration contract, and DomainBaselinePerm represents the group-level or domain-level security baseline policy. The policy orchestration and template engine provides administrators, security personnel, or business administrators with template-based parameterized policy configurations, avoiding the writing of arbitrary rules. It fills in parameters according to predefined policy formats and outputs structured policy instances. The predefined strategy form is the collaborative contract template provided by the collaborative contract and authorized work order submodule. Preferably, the strategy orchestration and template engine introduces Rego (OPA) as the execution backend. Preferably, the strategy orchestration and template engine introduces a conflict resolution algorithm, which preferably combines explicit denial-overrides with the principle of least privilege. The strategy and control module is used to output the access policy determination result and execute the access policy based on the determination result. The strategy and control module includes a strategy decision engine (PDP) submodule and a strategy execution point (PEP) submodule. The Policy Decision Engine (PDP) submodule integrates multiple access control models based on roles, attributes, and relationships, and combines them with policy instances generated by collaborative contracts to calculate executable access decisions, enabling online determination of access requests. The Policy Decision Engine (PDP) submodule takes into input standardized identity tokens and session context, subject-resource entity collaboration graph, structured resource objects, and structured policy instances. After calculation by the decision model, it outputs an access decision, which includes an executable constraint package and additional security action flags. The access decision is defined as Decision = {permit_or_deny, constraint_pack, security_mark}. The decision model is based primarily on ABAC, supplemented by RBAC, and further enhanced by ReBAC. The specific expression of the decision model is as follows: Decision = f( RBAC_base(user), ABAC_attr(user, resource, env), ReBAC_rel(graph, user, resource), Contract_ctx(contract, now, process_state), Policy_set(policy_instances, deny_overrides, permit_minimization) ), Here, RBAC_base(user) represents the basic qualifications and admission boundaries of the subject; ABAC_attr(user,resource, env) represents the attribute condition matching status; ReBAC_rel(graph, user, resource) represents the existence of the collaborative relationship and the satisfaction of path constraints; Contract_ctx(contract, now, process_state) represents the collaborative contract and its validity, revocation rules and state linkage constraints; and Policy_set(policy_instances, deny_overrides, permit_minimization) represents the matching and conflict resolution of the policy instance set. Preferably, the Policy Decision Engine (PDP) submodule is configured with a high-frequency decision caching mechanism to cache PDP decision results and generate a data constraint expression and template library. This data constraint expression and template library includes cached executable constraint packages for use by the Policy Execution Point (PEP) submodule. The result cache key is defined as hash(user_id, session_id, resource_type, action, scope_version). Where user_id represents the principal ID, session_id represents the session ID, resource_type represents the resource type, action represents the action, and scope_version represents the version number of the authorization-related facts. Preferably, the cache invalidation triggering events include organizational changes, job changes, termination of collaborative contracts, changes in process nodes, entity exit, and other events that cause cache invalidation. Preferably, the executable constraint package includes row-level constraints, column-level constraints, and index-level constraints. Preferably, the row-level constraints use a filter expression template, the column-level constraints use a standardized expression combining a field whitelist or blacklist with a desensitization function, and the indicator-level constraints use a combination of an indicator allow list, drill-down depth, and export restrictions. The Policy Execution Point (PEP) submodule deploys policy execution points across multiple access channels, including data querying, report access, process operations, API calls, and log retrieval, forming a distributed execution matrix that transforms policy decision results into unavoidable mandatory actions. The distributed execution matrix includes PEP-gateway, PEP-data service, PEP-reporting service, PEP-process engine, and PEP-log retrieval. The PEP gateway intercepts requests, verifies identity tokens and session contexts, calls the PDP to obtain decision results to control API calls, service calls, and third-party access requests, and injects executable constraint packages into downstream services. The downstream services process requests solely based on these executable constraint packages, without further determining permissions themselves, ensuring centralized and consistent access control logic. The PEP-data service executes row-level and column-level constraints during the query phase and index-level constraints during the export phase. After export, it automatically overlays watermarks and generates file fingerprints. The PEP-reporting service controls the visibility of directories and components, limits the displayable metrics and drill-down depth, and controls report export based on the executable constraint package. The PEP-process engine controls the visibility and editability of fields at the process node level based on the executable constraint package, and executes button and action controls. Process write-back operations are only allowed on the set of fields specified by the constraint package. The PEP-Log Retrieval incorporates logs as resource objects into the access control system, performs minimal disclosure by domain and responsibility, and anonymizes sensitive fields. Preferably, in the distributed execution matrix, different execution points parse the same constraint package based on a uniformly defined executable constraint package structure and implement corresponding constraints in their respective execution contexts, thereby achieving end-to-end control over the data access scope, content, and operational capabilities. The process linkage and lifecycle module is used to transform real-world state changes in the business system into calculable and triggerable event flows, thereby driving the automatic adjustment of collaborative contracts, strategy instances, executable constraint packages, and cached versions, achieving full lifecycle management from "activation to tightening to freezing to recycling." The process linkage and lifecycle module includes an event bus and a linkage controller. The event bus integrates status changes from the process engine, work order system, contract system, organizational and personnel systems, third-party collaboration platforms, and other collaborative business processes into unified events, and delivers them to the linkage controller for permission change processing. The event model is defined as Event = {type, entity_id, from_state, to_state, timestamp, emitter, signature}. Wherein, type represents the event type, entity_id represents the ID of the event object, from_state represents the state before the state transition, to_state represents the state after the state transition, timestamp represents the time the event occurred, emitter represents the source of the event, and signature represents the event signature or integrity verification information. The method for implementing the linkage controller from event to permission change includes: 1) Verify events: Check the signature, emitter whitelist, and time window to prevent forgery and replay. 2) Normalization and Mapping: Map the entity_id to the authorization object. 3) Trigger the lifecycle state machine: Drive permission state transitions according to event rules. 4) Issue changes: Update the policy instance, update the constraint package policy template parameters, increment the version number to invalidate the cache, and write to the audit and evidence index. The permission lifecycle state machine includes Grant (pending activation) → Active (activated) → Tighten (tightened) → Freeze (frozen) → Revoke (revoked) or Expire (expired). The triggering conditions of the state machine are defined by event rules. The event rule is written as follows: when type = a certain type of event and to_state = a certain set, a state transition is triggered, along with an action. The process linkage and lifecycle module introduces an automatic recycling algorithm. When to_state ∈ {Completed,Terminated} or now > end_time, all policy instances associated with cid are revoked and written to the sealed evidence index. The end-to-end auditing and evidence sealing module generates a traceable and verifiable log by analyzing audit events, constraint summaries, and exporting watermarks and file fingerprints. The end-to-end audit and evidence sealing module is strongly bound to three types of information: access requests, decision-making basis, and execution results. The audit event is defined as: Audit = {request_id, user, action, resource, decision, constraint_digest, policy_id, contract_id, result_summary, device, ip, time}. In this context, `request_id` represents the primary key for end-to-end tracing, `user` represents the subject identifier, `action` represents the access action, `resource` represents the resource object, `decision` represents the PDP decision result, `constraint_digest` represents the constraint package digest, `policy_id` represents the policy instance, `contract_id` represents the collaboration contract, `result_summary` represents the execution result digest, and `device`, `ip`, and `time` represent environment authentication fields, provided by the standardized identity token and session context. The constraint digest, `constraint_digest = hash(constraint_pack)`, is used to prove the allowed boundaries at that time. The exported watermark and file fingerprint are defined as: watermark_text = user_id + time + contract_id + policy_id + request_id; the file fingerprint is hashed and archived. Preferably, the end-to-end auditing and evidence sealing submodule incorporates the Isolation Forest algorithm for outlier detection; A method for multi-role data access control oriented towards industry collaboration, based on the aforementioned multi-role data access control system for industry collaboration, is characterized by comprising the following steps: (1) Initialization configuration: Construct resource objects and subject relationship collaboration graph, construct collaboration contract and fill in parameters, and generate strategy instance set and strategy version information. (2) Unified Identity Authentication: Initiate an access request, the unified identity and authentication adapter completes authentication and outputs a standardized identity token and session context. (3) Gateway interception and policy decision call: PEP—Gateway execution point intercepts access requests containing standardized identity tokens and session contexts, and sends a decision request to the policy decision engine PDP submodule; (4) Access Decision Result Determination: The Policy Decision Engine (PDP) submodule calls upon standardized identity tokens and session context, resource objects, subject-resource entity collaboration graphs, structured policy instances, and other information. The determination model outputs the access decision result and caches high-frequency decision results for use by the policy execution point (PEP) submodule. (5) Access Decision Result Execution: Each execution point of the Policy Execution (PEP) submodule enforces the interface call channel, data query channel, report channel, process channel, and log retrieval channel according to the executable constraint package, and outputs an execution summary. (6) Business Event Access and Permission Migration: The event bus and linkage controller unify state change events from the process system, work order system, contract system, organization management system, and third-party collaboration platform into a standardized event flow. Based on event rules, it drives the lifecycle state machine migration and generates corresponding change actions. It outputs lifecycle change instructions for contract and strategy instances, which are applied to the collaborative contract and authorized work order sub-modules and the strategy orchestration and template engine, respectively. Simultaneously, it triggers the incrementing of the data constraint expression and template library cache version number. (7) When to_state is Completed or Terminated, or when the current time exceeds the end_time of the collaboration contract, the module process linkage and lifecycle module revokes all policy instances corresponding to cid, and increments scope_version to invalidate the cache, ensuring that reclamation takes effect immediately. (8) The end-to-end audit and evidence sealing module generates audit events, generates export watermarks and overlays them onto the export results, calculates file fingerprint hashes and archives them.

[0013] The goal is to achieve fine-grained control over business data, report data, process data, interface calls, and log data through a collaborative graph of subject relationships, a strategy generation mechanism driven by collaborative contracts, a joint decision model, and a unified executable constraint package and multi-execution point enforcement mechanism.

[0014] Other similar embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art that are not disclosed herein.

[0015] The above embodiments are preferred embodiments of the present invention. Due to space limitations, the applicant has not used other embodiments, but this is not intended to limit the scope of the present invention. Any person skilled in the art can make some modifications without departing from the scope of the present invention; that is, all equivalent modifications made in accordance with the present invention should be covered by the scope of the present invention.

Claims

1. A multi-role data access control system for industry collaboration, comprising a subject and identity module, a resource registration and object modeling module, a collaboration contract and strategy instance module, a strategy and control module, a process linkage and lifecycle module, and a full-link audit and evidence sealing module, characterized in that: The subject and identity module outputs standardized identity tokens and session contexts, constructing a collaborative relationship graph between subjects and resource entities. The resource registration and object modeling module outputs structured resource objects. The collaborative contract and policy instance module constructs collaborative contracts and supports parameter writing, generating a set of structured policy instances. The policy and control module inputs the outputs of the aforementioned modules into the fused access control model, outputs access decisions, and deploys policy execution points in multiple access channels to execute distributed control behaviors based on the access decision results. The process linkage and lifecycle module constructs the state changes of collaborative services into a unified event flow through an event bus and linkage controller, and performs permission change processing. The end-to-end audit and evidence sealing module forms a traceable and provable log through audit events, constraint summaries, and exported watermarks and file fingerprints.

2. The multi-role data access control system for industry collaboration according to claim 1, characterized in that... The subject and identity module is used for unified identity authentication and to construct a subject resource collaboration graph. This module includes a unified identity and authentication adapter and a subject relationship and collaboration graph submodule. The unified identity and authentication adapter is used for unified access to multi-source authentication. It transforms authentication results into computable attributes through standardized identity representation and session context for subsequent module judgment. The unified identity and authentication adapter outputs a standardized identity token and session context. The token model is preferably an opaque token (Opaque Token) + session ID. The token contains only the minimum necessary declarations, including sub (subject identifier), org (organization), roles (basic role set), assurance_level (authentication strength level), and other necessary declarations, avoiding stuffing too much sensitive information into the token. The session context includes authentication method and strength, terminal trustworthiness, risk markers, bound collaborative identity mappings, and other content describing the session environment, which is read by the Opaque Token. The unified identity and authentication adapter is equipped with a risk-enhanced authentication module, employing step-up authentication for high-risk actions. The Authentication (Action-based escalation authentication) model performs secondary verification. The high-risk actions include data outsourcing actions, cross-domain extension actions, critical change actions, and other high-risk actions that require escalation authentication.

3. A multi-role data access control system for industrial collaboration according to claim 1, characterized in that... The resource registration and object modeling module is used to perform unified resource modeling on scattered business data, reports, processes, interfaces, and operation records, and output structured resource objects. The resource object is defined as Resource = {rid, type, domain, system, sensitivity, actions, attributes, lineage}, where rid is the unique ID of the resource in the system, type is the resource type, domain is the business segment or governance domain to which the resource belongs, system is the business system from which the resource originates, sensitivity is the sensitivity level of the resource, actions is the set of executable actions of the resource, attributes is the set of extended attributes of the resource, and lineage is the data lineage, which describes the reference relationship between resources.

4. A multi-role data access control system for industry collaboration according to claim 1, characterized in that... The collaborative contract and strategy instance module is used to construct standardized authorization templates and write structured strategy instances through parameters. This module includes a collaborative contract and authorization work order submodule and a strategy orchestration and template engine. The collaborative contract and authorization work order submodule is used to solidify authorization reasons and boundaries into machine-readable collaborative contracts, binding permissions to collaborative tasks and strongly associating them with actual business operations. The collaborative contract is defined as Contract = {cid, subject_set, resource_set, action_set, scope, constraints, start / end, approvals, ... The `revocation_rules` property is defined as follows: `cid` represents the contract ID, `subject_set` represents the set of authorized subjects, `resource_set` represents the set of authorized resources (indicating which resources are allowed to be accessed in this collaborative task), `action_set` represents the set of allowed actions, `scope` represents the authorized business boundary, `constraints` represents additional constraints, `start / end` represents the contract validity period, `approvals` represents approval and confirmation information, and `revocation_rules` represents revocation rules. The `subject_set` is the collaborative relationship graph between subject and resource entities constructed by the subject relationship and collaborative graph submodule. The `resource_set` is the structured resource object output by the resource registration and object modeling module. The collaborative contract and authorized work order submodule performs access permission contraction calculations using the least privilege closure. The least privilege closure `EffectivePerm = BasePerm(subject) ∩ ContractPerm ∩ DomainBaselinePerm`, where `BasePerm(subject)` represents the basic permissions possessed by the subject without considering this collaboration, `ContractPerm` represents the set of permissions explicitly authorized by the collaborative contract, and `DomainBaselinePerm` represents the group-level or domain-level security baseline policy.

5. A multi-role data access control system for industrial collaboration according to claim 1, characterized in that... The policy and control module is used to output access policy determination results and execute access policies based on the determination results. The policy and control module includes a policy decision engine (PDP) submodule and a policy execution point (PEP) submodule. The PDP submodule calculates executable access decision results by integrating multiple access control models based on roles, attributes, and relationships, combined with policy instances generated by collaborative contracts, thus achieving online determination of access requests. The PDP submodule takes into account standardized identity tokens and session context, subject-resource entity collaborative relationship graphs, structured resource objects, and structured policy instances. After calculation by the determination model, it outputs an access decision. The access decision includes an executable constraint pack and additional security action markers. The access decision is defined as Decision = {permit_or_deny, constraint_pack, security_mark}. The determination model is primarily ABAC, supplemented by RBAC, and overlaid with ReBAC. The specific expression of the determination model is as follows: Decision = f( RBAC_base(user), ABAC_attr(user, resource, env), ReBAC_rel(graph, user, resource), Contract_ctx(contract, now, process_state), Policy_set(policy_instances, deny_overrides, permit_minimization) )， Here, RBAC_base(user) represents the basic qualifications and access boundaries of the subject; ABAC_attr(user, resource, env) represents the attribute condition matching status; ReBAC_rel(graph, user, resource) represents the existence of collaborative relationships and the satisfaction of path constraints; Contract_ctx(contract, now, process_state) represents the collaborative contract and its validity, revocation rules and state linkage constraints; and Policy_set(policy_instances, deny_overrides, permit_minimization) represents the matching and conflict resolution of the policy instance set. The policy decision engine PDP submodule sets a high-frequency judgment caching mechanism to cache the PDP judgment results and generate data constraint expressions and template libraries. The data constraint expressions and template libraries cover cached executable constraint packages for the policy execution point PEP submodule to call. The result cache cache_key = hash(user_id, session_id, resource_type, action, scope_version), where user_id represents the subject ID, session_id represents the session ID, resource_type represents the resource type, and action represents the action. `scope_version` represents the version number of the authorization-related facts. The cache invalidation triggering events include organizational changes, job changes, termination of collaborative contracts, changes in process nodes, subject exit, and other events that cause cache invalidation. The executable constraint package includes row-level constraints, column-level constraints, and indicator-level constraints. The row-level constraints use a filter expression template. The column-level constraints use a standardized expression combining a field whitelist or blacklist with a desensitization function. The indicator-level constraints use a combination of an indicator allowable list, drill-down depth, and export restrictions.

6. A multi-role data access control system for industrial collaboration according to claim 1, characterized in that... The process linkage and lifecycle module is used to transform actual state changes occurring in the business system into calculable and triggerable event flows. Based on this, it drives the automatic adjustment of collaborative contracts, strategy instances, executable constraint packages, and cached versions, achieving full lifecycle management from "activation to tightening to freezing to recycling." The process linkage and lifecycle module includes an event bus and a linkage controller. The event bus integrates state changes from the process engine, work order system, contract system, organizational personnel, third-party collaboration platforms, and other collaborative businesses into a unified event and delivers it to the linkage controller for permission change processing. The event model is Event = {type, entity_id, from_state, to_state, timestamp, emitter, signature}, where... `type` represents the event type, `entity_id` represents the ID of the event object, `from_state` represents the state before the state transition, `to_state` represents the state after the state transition, `timestamp` represents the time the event occurred, `emitter` represents the event source, and `signature` represents the event signature or integrity verification information. The implementation method of the linkage controller from event to permission change includes: 1) Verifying the event: checking the signature, emitter whitelist, and time window to avoid forgery and replay; 2) Normalization and mapping: mapping `entity_id` to the authorized object; 3) Triggering the lifecycle state machine: driving permission state transition according to event rules; 4) Issuing changes: updating the policy instance, updating the constraint package policy template parameters, incrementing the version number to invalidate the cache, and writing to the audit and evidence index. The permission lifecycle state machine includes Grant (pending effect) → Active (effective) → Tighten (tighten) → Freeze (freeze) → Revoke or Expire, the state machine trigger condition is defined by event rules, which are written as follows: when type = a certain type of event and to_state = a certain set, a state transition is triggered with an action. The process linkage and lifecycle module introduces an automatic recycling algorithm. When to_state ∈ {Completed, Terminated} or now > end_time, all policy instances associated with cid are revoked and written to the sealed evidence index.

7. A multi-role data access control system for industrial collaboration according to claim 1, characterized in that... The end-to-end auditing and evidence sealing module forms a traceable and verifiable log through audit events, constraint digests, and exported watermarks and file fingerprints. This module is strongly bound to three types of information: access requests, decision bases, and execution results. The audit event `Audit = {request_id, user, action, resource, decision, constraint_digest, policy_id, contract_id, result_summary, device, ip, time}`, where `request_id` represents the end-to-end tracking primary key, `user` represents the subject identifier, `action` represents the access action, `resource` represents the resource object, `decision` represents the PDP decision result, `constraint_digest` represents the constraint packet digest, `policy_id` represents the policy instance, `contract_id` represents the collaboration contract, `result_summary` represents the execution result digest, and `device`, `ip`, and `time` represent environmental forensics fields provided by standardized identity tokens and session context. The constraint digest `constraint_digest = hash(constraint_pack)` is used to prove the allowed boundaries at that time. The exported watermark and file fingerprint `watermark_text = user_id + time + contract_id + policy_id + ...` request_id; the file fingerprint is hashed and archived. The full-link audit and evidence sealing submodule introduces the IsolationForest algorithm for outlier detection.

8. A multi-role data access control system for industrial collaboration according to claim 2, characterized in that... The subject relationship and collaboration graph submodule is used to construct a collaboration relationship graph between subject and resource entities, providing a computable, queryable, and determinate relationship network. This ensures that data access authorization is based on business relationship facts rather than identity or role labels. The subject relationship and collaboration graph submodule uses a property graph model to construct the collaboration relationship graph. In this property graph model, vertices represent entities, and edges represent relationships between entities. Both vertices and edges carry attributes. Entity types include subject classes, resource classes, and other types that can serve as vertices. Subject classes include users, organizations, positions, teams, third-party collaborating entities, and other types of subjects. Resource classes include projects, work orders, contracts, scheduling tasks, processes, and other business collaboration data resources. Relationships between entities include subordinate relationships, participation relationships, carrier relationships, approval relationships, regulatory relationships, and other relationship types representing connections between entities. Vertex attributes describe the entity's own characteristic information, and edge attributes describe the constraints and contextual information of the relationships between entities. The subject relationship and collaboration graph submodule uses relationship existence + The relationship path constraint performs relationship determination, judging whether there is a relationship link that meets the requirements from the subject to the resource, avoiding generalized authorization. The relationship path constraint includes the length, edge type, direction, validity period and other constraints of the relationship link. An optional path constraint rule includes: starting point type, ending point type, allowed edge sequence, maximum length and additional constraints. The subject relationship and collaboration graph submodule calls the structured resource object of the resource registration and object modeling module as the resource entity.

9. A multi-role data access control system for industrial collaboration according to claim 4, characterized in that... The policy orchestration and template engine is used to provide administrators, security personnel, or business administrators with template-based parameterized policy configurations, avoiding the writing of arbitrary rules. Parameters are filled in according to predefined policy forms, and structured policy instances are output. The predefined policy forms are collaborative contract templates provided by the collaborative contract and authorization ticket submodule. The policy orchestration and template engine introduces Rego (OPA) as the execution backend and introduces a conflict resolution algorithm. The conflict resolution algorithm preferably combines explicit denial-overrides with the principle of least privilege (Permit-minimization).

10. A multi-role data access control system for industrial collaboration according to claim 5, characterized in that... The Policy Execution Point (PEP) submodule deploys policy execution points across multiple access channels, including data query, report access, process operation, API call, and log retrieval, forming a distributed execution matrix. This matrix transforms policy decision results into unavoidable mandatory actions. The distributed execution matrix includes a PEP gateway, PEP data service, PEP report service, PEP process engine, and PEP log retrieval. The PEP gateway intercepts requests, verifies identity tokens and session context, calls the PDP to obtain decision results, controls API calls, service calls, and third-party access requests, and injects executable constraint packages into downstream services. Downstream services process requests solely based on these executable constraint packages, without further authorization checks, ensuring centralized and consistent access control logic. The PEP data service executes row-level and column-level constraints during the query phase. Level constraints are implemented, with indicator-level constraints executed during the export phase. After export, watermarks are automatically overlaid, and file fingerprints are generated. The PEP-report service controls the visibility of directories and components, limits the displayable indicators and drill-down depth, and controls report export based on the executable constraint package. The PEP-process engine controls the visibility and editability of fields at the process node level based on the executable constraint package, and controls buttons and actions. Process write-back operations are only allowed on the set of fields specified by the constraint package. The PEP-log retrieval incorporates logs as resource objects into the access control system, performs minimal disclosure by domain and responsibility, and desensitizes sensitive fields. Different execution points in the distributed execution matrix parse the same constraint package based on a unified executable constraint package structure and implement corresponding constraints in their respective execution contexts, achieving full-link control over the scope, content, and operational capabilities of data access.